UE5 Quest System
This page is part of the documentaiton for my UE5 Quest System

Quest Prerequisites

UE5 Quest System Version: 2.0

    What are Quest Prerequisites?

    Quest Prerequisites are conditions that need to be fulfilled before a quest or its objectives become accessible to the player.

    You can specify these prerequisites in the data table for each quest using the QuestPrerequisites map variable. In this map, each key represents a type of prerequisite, and the associated value provides the necessary details using our Prerequisite Syntax (see below).

    Prerequisites are categorized into internal and external types. Internal prerequisites are checked within the quest system itself, verifying the state of other quests.

    External prerequisites, on the other hand, use the Connected Systems BPI, enabling you to integrate conditions from other systems outside the quest system.

    Prerequisite Syntax

    Each prerequisite type can manage multiple conditions, which you delineate in the value field of the QuestPrerequisites map in the data table for your quest. For instance, if a prerequisite requires the completion of three specific quests, you'd choose Quest Complete as the key and set the value to quest1,quest2,quest3 using commas to separate each QuestRowName. For a single quest requirement, simply list that quest without any commas, like this: quest1

    The prerequisite syntax also supports values, enabling you to define more detailed conditions. For example, if you're using an experience system and want a quest to require a minimum player level of 10, you'd choose the Player Level prerequisite with a value of: level:10

    To set multiple conditions, like requiring a player level of 10 and a mining skill of 5, you'd format the value as: level:10,mining:5

    The quest system will then parse this syntax and call your isQuestPrerequisiteComplete (part of the Connected Systems BPI) function separately for each condition:

    • First call: PrerequisiteKey of level and a PrerequisiteValue of 10
    • Second call: PrerequisiteKey of mining and a PrerequisiteValue of 5

    Internal Prerequisites

    Internal prerequisites rely on the state of other quests within the system and don't require extra setup. To define them, use the quest row name in the value syntax. If you need to specify multiple quests for a single prerequisite type, separate their names with a comma.

    Quest Complete - The prerequisite is met when the specified quest(s) are in the Completed state.
    Quest In Progress - This prerequisite is fulfilled when the specified quest(s) are in the In Progress state.
    Quest Failed - The prerequisite is satisfied when the specified quest(s) are in the Failed state.

    How External & Custom Prerequisites work ...

    The video on the Connected Systems page also goes over setting up and using external prerequisites related to my other assets for player level, inventory, hotbar, equipment, and currency. I recommend reviewing those parts if you are struggling with understanding this part of the system.

    External & Custom prerequisite types are designed to work with the various Connected Systems in your game. To utilize custom prerequisites, you need to implement the isQuestPrerequisiteComplete function from the Connected Systems BPI in your player controller.

    Your other systems also need to have the capability of exposing these values so you can evaluate them against the values the quest system sends to this function as inputs. For guidance on setting up and implementing this function, refer to the Connected Systems chapter in this documentation.

    Once you've implemented the function, configure it to assess the inputs and return a boolean value indicating whether the custom prerequisite is met. The function receives three inputs: the Prerequisite Type (an enum), the Prerequisite Key, and the Prerequisite Value. The key and value are derived from your defined Syntax Value (see below).

    The isQuestPrerequisiteComplete function is your one-stop method for evaluating all custom prerequisites. Use the Prerequisite Type enum to identify which specific prerequisite you are checking. These custom types are designed as generic placeholders to accommodate a range of common requirements in your game's quest system. To use them you will need to write the code to handle checking them against your other systems (we go over this in that Connected Systems chapter I keep mentioning).

    In our demo world, we utilize custom prerequisites for both the quest and objective availability in the example with the light that turns on and off. This demonstrates how prerequisites can be effectively applied to individual objectives within a quest, adding depth and complexity to the gameplay experience.

    In the background, this prerequisite utilizes the Custom type with a value of lightbulb. Within our handler (see demo world's player controller), we interpret this specific requirement to check the current state of our actor (in this case, a lightbulb) and if it's turned on, we return true; if it's off, we return false. The quest system takes care of the rest. Your role is simply to assess the condition based on the inputs provided and return a true or false value accordingly, informing the quest system whether the prerequisite is met.

    You should keep what you do inside this handler as light as possible as these prerequisites can be evaluated from both the client and the server at different times for different reasons. For maximum efficiency it is better to use variables in here, and delegate the actual functionality of updating and getting the values set to these variables in another external process (from your own side).

    List of External Prerequisite Types

    If you would like examples of most of these functions in action have a look at the Connected Systems page for a run through using my Inventory and Experience Systems.

    Player Level - This prerequisite is intended for integration with your game's experience system. It can be used to evaluate whether the player's level meets or exceeds a specified value. For instance, if you require the player to have a minimum level of 20 and a mining skill of at least 5, you would use the syntax: level:20,mining:5.This syntax can then be interpreted by your isQuestPrerequisiteComplete that the player's overall level should be 20 or higher and their mining skill is 5 or greater.
    Player Class - This prerequisite is to check if the player belongs to a specific class, such as Warrior, Mage, etc. This type of prerequisite ensures that only players of a designated class can access certain quests or objectives, aligning with class-specific storylines or challenges.
    Inventory - This prerequisite is to check if the player possesses specific items in their inventory. For instance, if you need to ensure the player has a fishing rod, you would use just FishingRod as your syntax, referring to the item's row name in your data. If you also want to verify that the player has at least 5 pieces of FishingBait, the syntax would be FishingRod,FishingBait:5. In this context, if a quantity isn't specified for an item, the default assumption in your system should be that at least one of that item is required. You can optionally provide it if you prefer, so the previous syntax could also look like: FishingRod:1,FishingBait:5
    Hotbar - This prerequisite is to check if the player has a specific item or items on their hotbar. For example, to check if the player has a HealingPotion on their hotbar, you would use HealingPotion as your syntax if HealingPotion was your healing potion's ItemRowName. If you want to ensure the player has at least 5 HealingPotions and 3 ManaPotions, the syntax would be HealingPotion:5,ManaPotion:3. This setup allows you to confirm not just the presence of specific items but also their quantities directly on the player's hotbar.
    Equipment - This prerequisite is to check if the player is currently wearing or has equipped a specific piece of equipment. The value for this check should be the row name of the equipment item from your data. For instance, if you need to verify that a player is wearing an IronHelmet, you would use IronHelmet as the value in your prerequisite. Alternatively you could use this define an equipment slot that should not be empty, and use it like that. How it is used is up to you (you have to code the bridge between the quest system and your system, this is part of the connected systems). I am simply providing you with a common starter point and the foundation to work from.
    Currency - This prerequisite is to check if the player has a sufficient amount of a specific type of currency. You would specify the required amount of currency the player needs to have for this prerequisite to be met. For example, if a quest requires the player to have 100 gold coins, the syntax might look something like gold_coins:100, where 'gold_coins' is the currency row name and '100' is the amount required.
    Custom - This prerequisite allows you to define a unique condition that must be met for the quest or objective to become available. This type of prerequisite gives you the flexibility to implement any specific requirement that isn't covered by the standard types. To introduce new prerequisite types, you'll need to modify the E_Quest_Prerequisites enum (in the Blueprints/Variables/Enums/ folder). However, it's crucial to heed any warnings or guidelines provided in the enum's description to ensure your custom prerequisites integrate seamlessly with the quest system.

    Objective Prerequisites

    Just as with quests, Quest Objectives can also be set with prerequisites, allowing you to control when an objective can be completed. This feature enables you to create a more dynamic and interdependent quest structure where the completion of certain objectives might depend on various conditions being met.

    Reevaluating Availability

    One of the Quest Options is Reevaluate Availability?. When this is set to true, the system will periodically reassess the prerequisites for a quest that is currently marked as available.

    If, upon reevaluation, the prerequisites are not met, this option will cause the Quest State to switch back to 'Not Available.' This ensures that the quest's availability accurately reflects the current state of its prerequisites at all times.

    This documentation and asset version are new. If you encounter any bugs or if anything doesn't make sense, please let me know.